Many workers in the computer and computer peripheral arts are today trying to push the price/performance/reliability envelope of computer systems further than ever before. State of the art systems require ever increasing on-line storage capacity and reliability without a corresponding detrimental impact on speed. In order to provide access to such ever increasing volumes of data at a reasonable speed and cost, many new technologies have been developed. One very popular storage technology is redundant arrays of inexpensive disks (RAID).
The technology behind RAID includes both a general hardware architecture and a disk array controller firmware architecture. With respect to the disk controller firmware architecture, one of the more popular architectures is RAID Level 5. The RAID Level 5 architecture, as well as RAID generally and the various RAID Levels, are described in detail in Patterson et al., "A Case for a Redundant Arrays of Inexpensive Disks (RAID)", ACM SIGMOD Conference, Chicago, Jun. 1-3, 1988, incorporated herein by reference.
As described therein, disk data are divided into stripes. See also FIG. 3, which illustrates a RAID Level 5 disk set including four disks, DISK1 -DISK4, and a stripe width of five blocks. Stripes 301, 302, and 303 contain data of two kinds, host data D and meta-data P. Host data D, which is the information stored, retrieved and manipulated by the host computer, is for convenience referred to hereinafter simply as data D. Meta-data P is used exclusively by the disk array controller and perhaps other disk subsystem components for the control and maintenance of the disk array system. For example, one type of meta-data P may be parity information. Stripes are recorded as sequential blocks on a plurality of different disk drives. Each stripe includes a plurality of data blocks D and one additional set of blocks called parity blocks P. The parity blocks P contain the logical exclusive-OR (XOR) of the plurality of data blocks D, and is recorded on an additional disk drive. Conventionally, the parity blocks P are distributed among all the disk drives of an array, as shown in FIG. 3, in order to avoid drive contention during write operations. The use of parity blocks P improves availability of all of the data in a stripe. When one drive is unavailable, for example, the missing data block from a stripe can be reconstructed from the parity block and the available data blocks. The contents of the parity block is simply XORed with the data blocks remaining. The result of this XOR operation is the data from the missing drive. Once such a drive has been repaired, data can be restored to the repaired drive using the parity blocks and data blocks from each good drive in similar fashion.
A typical RAID-based disk controller 101 is shown in FIG. 1. The controller is connected to a host computer (not shown), through a host port 103. Input/output (I/O) transactions are received through the host port by a host I/O processor 105. The host I/O processor is responsible for receiving commands from the host computer to the RAID array and for transferring data and command status responses from the RAID array back to the host computer. Commands from the host computer are typically requests to perform an operation on a number of blocks, i.e., a logical block count (LBC), beginning with a specified logical block address (LBA) within the RAID array.
The RAID disk controller also has a disk array interface port 107 which communicates with a plurality of physical disk drives 109. Data I/Os and other commands to be executed by the physical disk drives of the RAID array are processed by a disk array I/O processor 111 executing RAID Level 5 algorithms. The host commands relating to logical locations (LBA, LBC) are processed into a plurality of physical I/O operations which are in turn processed by a physical disk handler 115 into physical I/O commands for specific physical disk drives 109. For example, a disk write of several blocks may be organized into stripes and divided into individual disk I/O operations. Such common operations are described in detail in Patterson et al.
In order to improve the efficiency of RAID controllers, it has become a common practice to provide a cache 113, logically disposed between the host I/O processor 105 and the disk array I/O processor 111. For example, Row et al. In U.S. Pat. No. 5,163,131, issued Nov. 10, 1992, describe an architecture for a large file server including a front end cache. Goodlander et al. disclose a front end caching system in the context of a data storage system including a plurality of disk drives, in U.S. Pat. No. 5,257,367. The caching system 113 is typically a separate software process or set of subroutines using the same system logical block references as the host I/O processor 105 because the data cached is that data frequently requested by the host computer. Therefore, use of logical block references by the cache 113 is most efficient. Caching of data is helpful because the host may request data from the same logical location many times without modification. When such frequently requested data is found in the cache 113, it may be sent to the host port by the host I/O processor 105 without having to perform a physical I/O to the RAID array. Such a cache 113 may also be helpful during write operations because valid old data which has been previously cached need not be retrieved from the physical disks to be XORed with the parity stripe before overwriting. The valid old cached data can be XORed with the parity stripe and then the new data both cached and written to the physical disks. Also caching of write operations permits the disk array controller to report command completion very quickly, an operation referred to as "fast writes".
One problem with conventional RAID disk controller design is that a write operation is usually preceded by at least one disk drive read operation in order to retrieve the parity stripe from the RAID array. Sometimes this problem is solved by consolidating writes into full-stripe writes, wherein a new parity is generated for the full stripe. However, there is no assurance that a full-stripe write, or optimized write, as it is known in the art, will always be obtained from consolidations of host write commands.
As discussed above, systems with no caching and systems with only front end caching are known. Systems with only back end caching are also known. However, front end caches have never been combined with back end caches. Workers in this field of art have not combined front end caches and back end caches in a single RAID disk controller system because such a combination was not thought to provide an advantage warranting the additional cost and complexity of the resulting system. It was recognized that the front end cache would improve the host I/O performance and the back end cache would improve the disk array I/O performance during write operations, but the advantages are outweighed by the cost and complexity of additional cache memory, separate cache control systems and potential negative interactions between the front end cache system and the back end cache system. Potential negative interactions include referencing a block multiple times during a single operation, resulting in additional cache look ups.